FIG. 1 is a simplified network illustration. The App x and App y in the User Equipment (UE) communicates with their respective server located on the Internet via the mobile operators Radio Access Network (RAN), Core Network (CN) and service network. To take the Adaptive Bit Rate feature as an example, for this feature the video server has the video encoded in different bitrates, and the UE selects the format based on throughput estimations. End user experience or Quality of Experience (QoE) is a differentiator for mobile operators and internet service providers. Applications are attempting to be adaptive to ensure a good QoE, e.g. by adapting to varying throughput by changing to an encoded format with a suitable bitrate. Currently this is done by trying to estimate the throughput between the server and the application in the UE, e.g. based on measured link bit rate or round trip times (RTT). How frequently the bitrate can be changed varies. A typical interval for adaptive video streaming would be every 2-5 seconds.
FIG. 2 is a schematic diagram of Evolved Packet Core (EPC) architecture (non-roaming) for access to a cellular network in accordance with a Third Generation Partnership Project (3GPP) standard. Evolved Packet System (EPS) is the Evolved 3GPP Packet Switched Domain and consists of EPC and an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The architecture is defined in 3GPP Technical Specification (TS) 23.401, which also defines the Packet Data Network (PDN) Gateway PGW, the Serving Gateway (SGW), the Policy and Charging Rules Function (PCRF), the Mobility Management Entity (MME) and the user equipment (UE, a radio device e.g. a mobile phone). The Long Term Evolution (LTE) radio access network, E-UTRAN, comprises one or more base stations called evolved Node B (eNB).
The overall E-UTRAN architecture and is further defined in for example 3GPP TS 36.300. The E-UTRAN comprises eNBs providing the E-UTRAN user plane (radio interface user plane layers such as Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC) and physical layer (PHY)) and control plane (Radio Resource Control, RRC, in addition to the above user plane protocol layers) protocol terminations towards the UE. The eNBs are interconnected with each other over the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC, more specifically to the MME over the S1-MME interface and to the SGW over the S1-U interface.
A new RAN feature has been specified in 3GPP for LTE in Release 12 (Rel-12). It is called LTE Dual Connectivity (DC). As the name implies it means that a UE can be connected to multiple eNBs at the same time, i.e. send and receive data on multiple paths as illustrated in FIG. 3 (showing two different options for user plane handling of LTE DC). E-UTRAN supports DC operation whereby a UE comprising multiple receivers and transmitters (RX/TX) in RRC_CONNECTED state is configured to utilise radio resources provided by two distinct schedulers, located in two different eNBs connected via a non-ideal backhaul over the X2 interface.
In the DC solution, concepts of Master eNB (MeNB) and Secondary eNB (SeNB) are introduced. eNBs involved in dual connectivity for a certain UE may assume two different roles: an eNB may either act as an MeNB or as an SeNB. In dual connectivity, a UE is connected to one MeNB and one SeNB.
In DC, the radio protocol architecture that a particular bearer uses depends on how the bearer is setup. Three alternatives exist, Master Cell Group (MCG) bearer, Secondary Cell Group (SCG) bearer and split bearer.                For MCG bearers, the MeNB is user plane connected to the SGW via S1-U, the SeNB is not involved in the transport of user plane data.        For split bearers, the MeNB is user plane connected to the SGW via S1-U and in addition the MeNB and the SeNB are interconnected via X2. This is shown as the right hand side option of FIG. 3.        For SCG bearers, the SeNB is directly connected with the SGW via S1-U. This is shown as the left hand side option in FIG. 3.        
In 3GPP, Quality of Service (QoS) is managed on a per bearer level from the CN. The RAN is responsible for setting up the radio bearers, radio resource management, and enforcing QoS according to the bearer QoS Profile—over the radio (e.g. LTE-Uu) interface in the downlink (DL) and over the transport network in the uplink (UL). The architectures differ slightly over the different radio access networks (e.g. 3G/Wideband Code Division Multiple Access (WCDMA) and 4G/LTE) but the QoS principles are similar (at least for 3G and 4G networks). FIG. 4 shows the EPS bearer architecture and the different levels of bearers building up the end-to-end connection for the UE.
3GPP defines the concept of a PDN. A PDN is in most cases an IP network, e.g. Internet or an operator IP Multimedia Subsystem (IMS) service network. A PDN has one or more names. Each name is defined in a string called Access Point Name (APN). The PGW is a gateway towards one or more PDNs. A UE may have one or more PDN connections. A PDN connection is a logical IP tunnel between UE and PGW, providing the UE access to a PDN. The setup of a PDN connection is initiated from the UE.
Every PDN connection consists of one or more EPS bearers. See 3GPP TS 23.401 section 4.7.2 for a description of the bearer concept. A bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PGW. Each bearer on a particular access has a unique bearer ID. On the 3GPP access, the bearer is end-to-end between UE and PGW. Every PDN connection has at least one bearer and this bearer is called the default bearer. All additional bearers on the PDN connection are called dedicated bearers.
A bearer carries traffic in the form of IP packets. Which traffic is carried on a bearer is defined by filters. A filter is an n-tuple where each element in the tuple contains a value, a range, or a wildcard. An n-tuple is also known as an IP flow.
An example of a 5-tuple is (dst IP=83.40.20.110, src IP=145.45.68.201, dst port=80, src port=*, prot=TCP). This 5-tuple defines a source (src) and destination (dst) IP address, a source and destination port, and a protocol. The source port is a wildcard. Traffic matching this 5-tuple filter would be all Transmission Control Protocol (TCP) traffic from IP=145.45.68.201 to IP=83.50.20.110 and port=80.
A traffic flow template (TFT) contains one or more filters. Every bearer has a TFT. One bearer within a PDN connection and access may lack an explicit TFT (this bearer is typically the default bearer). Implicitly such a bearer has a TFT with a single filter matching all packets.
Bearers are used for example to provide different quality of service and characteristics. When a UE is active it has a default bearer where all traffic goes. The network or the UE can initiate a secondary/dedicated bearer with a different quality/characteristics. The network can detect a flow that should have a dedicated bearer by inspecting the traffic, or the network can be informed by an Application Function (AF), with reference to FIG. 2, an entity in the operators IP services, or the network can be informed by the UE about the need for a dedicated bearer. For example, if a video session is detected. The network then could trigger the establishment of a new bearer, apply a filter to separate which traffic should go on which bearer, i.e. the TFT. This TFT is also sent to the UE so that the UE can put UL traffic on the correct bearer. In DL, TFTs are used to map/select which transport tunnel (GTP tunnel) and bearer a certain flow should be sent on. A TFT can comprise the following identifiers:                Source Address and Subnet Mask        Protocol Number (IPv4)/Next Header (IPv6)        Destination Port Range        Source Port Range        IPsec SPI        TOS (IPv4)/Traffic Class (IPv6) and Mask        Flow Label (IPv6)        
For example, the PGW will, when receiving an IP packet from Internet with destination IP address, select a UE context based on the destination IP address. This means that the UE context is identified with an UE IP address and contains a number of TFTs associated for each dedicated bearer established for the UE. The PGW then checks if there is a TFT associated with information included in the received IP packet in the UE context and try to match the received IP packet with the TFT, and if there is a match send the packet on the dedicated bearer associated with that TFT. Similarly for the UE, when an UL packet is sent from the higher layer parts of the UE, e.g. an app, and received by the lower layer of the UE, e.g. where the radio protocols reside, there is a check if there is a TFT that matches and if there is match then the UL packet is sent on the dedicated bearer associated with that TFT.